Exchange Server 2010 Autodiscover : Autodiscover Concepts

We know several Exchange 2007 organizations that limped along seemingly just fine with Autodiscover improperly configured or just plain ignored. However, when Autodiscover has been neglected this inevitably signals an Exchange organization with other problems—and this is even truer in Exchange 2010 than in Exchange 2007. Autodiscover is more than just a way to ease administration of Outlook client profiles. Other Exchange components, servers, and services also use Autodiscover to find the servers and settings they need to communicate with. In order for the Outlook 2007 or Outlook 2010 client to leverage many of the advanced features of Exchange 2010, including the new high availability features, the client depends on a functional Autodiscover service. And if you want to use the external calendar sharing or Office Communications Server integration, you'd better get Autodiscover squared away.

The good news, though, is that in order to properly plan and deploy Autodiscover, you have to work through some of the most potentially confusing aspects of an Exchange 2010 deployment. Once you've got these issues solved, you will have headed off some confusing and annoying errors that might otherwise cause problems down the road. These issues include namespace planning and certificate management. Trust us that getting these issues sorted will make your client access deployment and your overall management tasks a lot easier.

1. What Autodiscover Provides

We made the point that Autodiscover is a necessary part of your Exchange deployment. It is necessary for far more reasons than that it makes configuring your Outlook 2007 and 2010 clients easier. In Exchange 2007, the clients did benefit a great deal, which is part of the reason why many people did not see the point of learning about the service. In Exchange 2010, the non-client benefits get better, but the client benefits do, too. Some of the information provided by Autodiscover includes the following:

• Client Access server names that Outlook should use to access a user's mailbox

• Configuration URLs for the offline address book (OAB)

• Configuration URLs for free and busy information

• Outlook profile configuration information

1.1. Client Benefits

Exactly what benefits you get from Autodiscover depend on which client you're using:

• Outlook 2007 (SP2 recommended) and Outlook 2010 fully supports Autodiscover. Outlook 2010 will support Autodiscover when it's released. Outlook versions prior to 2007 do not use Autodiscover, but they don't support many of the other cool features of Exchange 2010—so why are you still using them?

• Windows Mobile 6.1 and later support Autodiscover for the most part; they don't support the use of DNS SRV records, instead reverting to the baseline Outlook 2007 behavior. Earlier versions of Windows Mobile, sadly, don't support Autodiscover, but they also support down-level versions of the Exchange ActiveSync protocol, which means you've already lost some cool functionality.

• Entourage 2008 for the Macintosh, which still relies on the WebDAV protocol for mailbox access, supports some limited Autodiscover benefits, but the forthcoming update to Entourage 2008 that fully supports Exchange Web Services will also take full advantage of Autodiscover. If you're a Mac user, this new version of Entourage is the only way to integrate with Exchange.

Although these are the main Autodiscover-aware clients, they're not the only ones. For example, the Microsoft Office Communicator client and devices use Autodiscover and Exchange Web Services. The behavior of Autodiscover has been clearly documented by Microsoft, so other third-party clients and devices may also make use of it. Features that Outlook and Windows Mobile will leverage include the following:

Support for DNS A Records

By default, external clients attempt to find the Autodiscover service through DNS lookups against well-known hostname (A) records. While CNAME records can be used, they cause a nonconfigurable security warning to be displayed that some organizations find provides a less than desirable user experience. The CNAME warnings can be disabled via the Registry, though. See this Microsoft Knowledgebase article for more information: http://support.microsoft.com/?id=956528.

Support for DNS SRV Records

Due to popular demand, the Exchange and Outlook teams provided support for the use of Service Locator (SRV) records for organizations that couldn't use A records and didn't want to use CNAMEs. Unfortunately, use of the SRV record also results in a warning dialog, so it's still not the best approach (though it can be disabled via the Registry).

Support for Active Directory Service Connection Point Objects

Domain-joined clients that can contact Active Directory—effectively any Windows machine running Outlook 2007 or greater—can make use of an Active Directory feature called service connection points (SCPs). SCPs provide a number of benefits that aren't available with plain DNS lookups. SCPs allow internal clients to locate resources via SCP objects within the Active Directory.

Internal Organization Settings

Services on Exchange 2010 and Exchange 2007 Client Access servers have both internal URLs for clients within the firewall (such as Outlook and Communicator on domain-joined Windows machines) and external URLs for pretty much everything else. Internal settings use the appropriate Exchange server FQDNs by default, unless you modify them (such as when using load balancers).

External Organization Settings

External settings allow services to be reached through Internet-available hostnames and FQDNs. For some reason, many organizations don't like publishing the internal FQDNs of their Exchange servers. Using external settings may also ensure that connections are load balanced or sent through firewalls, such as ISA Server 2006 or Forefront Threat Management Gateway.

Location of the User's Mailbox Server

The location of the user's mailbox server is in Active Directory, stamped on the user object. However, with the use of Exchange 2010 high availability features and the RPC Client Access service on the Client Access server, Outlook may connect to one of several Client Access servers. With the RPC Client Access Array feature, the Client Access server that Outlook is using may change quickly. Autodiscover can get this information, which allows the client to quickly reconnect to the correct Client Access server.

Location of the Availability Service

Calendar items are stored in each user's mailbox. However, their free/busy information has historically been placed in a system public folder, which could suffer from latency due to replication lag. The Exchange Availability Service allows current information to be quickly looked up by clients (both in the organization and in federated organizations) as they need it, rather than having them dependent on stale data in public folders.

Location of the Exchange Unified Messaging Service

Although voicemail messages created by Exchange Unified Messaging are placed in the mailbox, additional controls and features are available to users through this Exchange Web Service.

Location of the Offline Address Book Service

If you have taken advantage of the ability to publish your OABs to web virtual directories, your clients can use HTTP to download them in the background (using the Windows Background Internet Transfer Service, or BITS) instead of having to connect to a system public folder.

Outlook Anywhere settings

Having the external URL information is a good start for clients outside your corporate firewall, but more settings are necessary for a successful Outlook Anywhere session to be established, such as the certificate validation name.

1.2. Server Benefits

Autodiscover isn't just useful for clients connecting to the Exchange server infrastructure; it's also useful for other servers, both within the organization and without:

• Servers within the same organization and Active Directory forest use Autodiscover to locate various services on a user's behalf. For example, when a user performs a logon to Outlook Web Access, the CAS role handling the OWA session needs several of the pieces of information provided by Autodiscover. Using Autodiscover reduces the load on Active Directory domain controllers and global catalog servers and removes reliance on cached information. This is true whether you're in a mixed Exchange 2010/2007 organization or are deploying Exchange 2010 fresh.

• Servers within the same organization but in a different Active Directory forest depend on cross-forest service connection points and internal Autodiscover to cross the forest boundaries and discover the appropriate servers to use. In this situation, one CAS server in the source forest will often act as a proxy for the appropriate services in the target forest, or it may simply redirect the client. In multiple forest deployments, the use of Autodiscover is pretty much mandatory to ensure that Exchange servers in separate forests can interoperate properly.

• Servers within separate federated organizations require the use of the external Autodiscover information to reach federated Availability services. This, plus the relevant authentication information, allows users to securely share calendar and free/busy information with their counterparts in federated Exchange 2007 and 2010 organizations. To share availability information with a federated Exchange 2007, you have to jump through a number of hoops. With other Exchange 2010 organizations, the new Windows Live–based Federation Gateway greatly simplifies the configuration and management of these types of operations.

So, let's take a look at the nitty-gritty of how Autodiscover works.

2. How Autodiscover Works

Don't be fooled by the seeming complexity you're about to see. Autodiscover is pretty simple to understand. The biggest complications come from certificates and namespace planning, which we'll get to in a bit.

2.1. The Service Connection Point Object

The first piece of the Autodiscover puzzle lies with the Service Connection Point (SCP) object. As each CAS role instance is installed into your organization, it creates an SCP object in the Configuration-naming partition of the Active Directory domain to which it is joined, at the following location:

CN=<CAS Server NetBIOS Name>, CN=Autodiscover, CN=Protocols, CN=<CAS Server
NetBIOS Name>, CN=Servers, CN= Exchange Administrative Group
(FYDIBOHF23SPDLT), CN=Administrative Groups, CN=<Organization Name>,
CN=Microsoft Exchange,CN=Services

Here's what a typical SCP object looks like when dumped from the LDP (LDP.EXE) tool:

Expanding base 'CN=HNLEX05,CN=Autodiscover,CN=Protocols,CN=HNLEX05,CN=Servers ,
CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups ,
CN=Ithicos Solutions,CN=Microsoft Exchange,CN=Services,CN=Configuration ,
DC=ithicos,DC=com' ...
Getting 1 entries: 
Dn:  CN=HNLEX05,CN=Autodiscover,CN=Protocols,CN=HNLEX05,CN=Servers,
CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
Groups,CN=Ithicos Solutions,CN=Microsoft Exchange,CN=Services,
CN=Configuration,DC=ithicosDC=com
cn:  HNLEX05;
distinguishedName:  CN=HNLEX05,CN=Autodiscover,CN=Protocols,CN=HNLEX05,
CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
CN=Administrative Groups,CN=Ithicos Solutions,CN=Microsoft Exchange,CN=Services,
CN=Configuration,DC=ithicos,DC=com;
dSCorePropagationData:  0x0 = (  );
instanceType:  0x4 = ( WRITE );
keywords (2):  Site=Redmond; 77378F46-2C66-4aa9-A6A6-3E7A48B19596;
name:  HNLEX05;
objectCategory:  CN=Service-Connection-Point,CN=Schema,CN=Configuration
DC=ithicos,DC=com;
objectClass (4):  top; leaf; connectionPoint; serviceConnectionPoint;
objectGUID:  ce804393-df59-4152-9cc2-d2701d069479;
serviceBindingInformation: 
https://HNLEX05.ithicosithicos.com/Autodiscover/Autodiscover.xml;
serviceClassName:  ms-Exchange-AutoDiscover-Service;
serviceDNSName:  HNLEX05;
showInAdvancedViewOnly:  TRUE;
systemFlags:  0x40000000 = ( CONFIG_ALLOW_RENAME );
uSNChanged:  7754800;
uSNCreated:  7754800;
whenChanged:  6/7/2009 2:48:22 PM Pacific Daylight Time;
whenCreated:  6/7/2009 2:48:10 PM Pacific Daylight Time;

					  

• The objectClass property includes the serviceConnectionPoint type. This identifies the entry as an SCP, allowing it to be easily searched.

• The serviceClassName property identifies this particular SCP as an ms-Exchange-AutoDiscover-Service entry. The computers searching for Autodiscover records can thus determine that this is an entry pertaining to Autodiscover and that they should pay attention to it. The client searches the configuration-naming context for any objects that have a serviceClassName= ms-Exchange-Autodiscover-Service. Using the combination of objectClass and serviceClassName allows computers to efficiently find all relevant SCP entries (through an indexed search from a domain controller) without knowing any computer names ahead of time.

• The serviceBindingInformation points to the actual Autodiscover XML file that the client should access in order to retrieve the current Autodiscover information.

• The keywords property holds additional information that the clients use. Specifically, take note of the Site= value. This value helps you control site affinity, ensuring that clients and servers aren't using servers in far-off sites to provide their Exchange services.

The rest of the properties on an SCP object are fairly standard for Active Directory objects, so we won't discuss them further.

Now that you know what a service connection point is and where they're located, you're mostly set. The distinguished name of each SCP object uniquely identifies the host associated without that object. If the client search returns multiple SCP objects that the client will use, it will select between them according to alphabetic order.

Note also that a CAS role instance only publishes its corresponding SCP object to Active Directory when it is installed. If you change something about the CAS—such as which site it's located in—it will not update its SCP object. You have to do that manually. The best way is to use Exchange Management Shell. Here is a sample command:

Set-ClientAccessServer -Identity 

"<CAS Server NetBIOS Name>" -AutodiscoverServiceInternalURI 

"https://<CAS Server FQDN>/autodiscover/autodiscover.xml" 

-AutoDiscoverSiteScope "<Site Name 1>", "<Site Name 2>"

2.2. DNS Options

The SCP is used when the client or server is joined to an Active Directory domain and can retrieve the search from the domain controllers. When the discovering computer is external or not domain joined, another mechanism is used: DNS lookups.

The following list describes the DNS lookups that are performed for the Autodiscover service in a given domain. For this example, let's use the user [email protected]. The client (or server) takes the domain portion (somorita.com) of this address and performs the following lookups in order until it finds a match:

If the requested hostname is returned through either a CNAME record or an SRV record, then be aware that your clients (Outlook in particular) will display a warning dialog with the following text:

Allow this website to configure [email protected] server settings?
https://mail.somorita.com/autodiscover/autodiscover.xml
Your account was redirected to this website for settings.
You should only allow settings from sources you know and trust.

This warning will appear every time the client performs Autodiscover unless you check the Don't Ask Me About This Website Again check box. You can also prepopulate the Registry key to prevent this warming. See the Knowledge Base article at http://support.microsoft.com/?id=956528.

Note that Autodiscover expects the use of SSL. Don't publish it over insecure HTTP and expect clients to be happy about it. You have a lot of sensitive information going through Autodiscover, including user credentials. As a result, SSL certificate considerations will play a large part in your Autodiscover configuration.

2.3. Two Step-by-Step Examples

Enough theory. Let's dive into our example with the ithicos.com domain and show you a walkthrough of a common scenario: a domain-joined Outlook 2007 SP2 client performing Autodiscover behind the organization firewall. To illustrate this scenario, we'll use a tool every Exchange administrator should know well: the Outlook Test E-mail AutoConfiguration tool, shown in Figure 1. As shown in this example, when using this tool be sure to uncheck the Use Guessmart and Secure Guessmart Authentication options.

Figure 1. Using the Test E-mail AutoConfiguration tool

You can access this tool from Outlook 2007 and later by holding down the Ctrl key while right-clicking the Outlook icon in the notification area on the taskbar. This opens the menu shown in Figure 2. From this menu, select the Test E-mail AutoConfiguration option.

Figure 2. Accessing the Test E-mail AutoConfiguration tool

When a domain-joined machine performs Autodiscover, it steps through the following process:

There are five key sections to note in Listing 1:

• The User and Account sections list the user information for the authenticated user.

• The EXCH protocol section (identified by the EXCH tag) is MAPI RPC over TCP, or traditional MAPI connections. These settings control how Outlook will connect inside the firewall, over a VPN, or in other situations where direct connectivity via MAPI is possible. The URLs provided in this section are based on the InternalURL values.

• The EXPR protocol section (identified by the EXPR tag) is Outlook Anywhere—RPC over HTTPS. These settings control how Outlook connects over slow connections or when a direct MAPI connection is not possible. The URLs provided in this section are based on the InternalURL values.

• The WEB protocol section (identified by the WEB tag) is used for OWA and other types of clients. The URLs provided in this section are for clients and are based on the ExternalURL values.

If the client had been outside the firewall, it would have followed a similar process, but instead steps through the hostnames and URLs as described in the previous section on DNS names. An external client (for the domain somorita.com) using Autodiscover goes through these steps:

To help step through and troubleshoot external connectivity, you should be aware of the Exchange Remote Connectivity Analyzer tool, available online from http://testexchangeconnectivity.com/. This Microsoft tool provides a secure, reliable suite of tests to help diagnose problems with not only Autodiscover but all of the web-based Exchange remote client access protocols.

3. Advanced Autodiscover Concepts

If you're reading this far, you've gotten through the basics of Autodiscover. There are some advanced concepts we need to share with you: how site affinity works (and how to manage it) and how to configure Autodiscover to work with multiple forests.

3.1. Site Affinity

To understand the point of site affinity, consider an organization that has multiple locations—we'll say in Seattle, Washington (code SEA); Toledo, Ohio (code TOL); and New Orleans, Louisiana (code MSY). There are Exchange servers and users in each of these locations. The links between these locations run over WAN links from Seattle to Toledo and Toledo to New Orleans; it is neither optimal nor desired to allow users in Seattle to use Client Access servers in New Orleans (or vice versa). Using site affinity, we can use the following commands to help ensure this does not happen:

Set-ClientAccessServer -Identity "sea-cas01" 

-AutodiscoverServiceInternalURI "https://sea-cas01.somorita.com/

autodiscover/autodiscover.xml" -AutodiscoverServiceSiteScope 

"Site-SEA","Site-TOL"

Set-ClientAccessServer -Identity "sea-cas02" 

-AutodiscoverServiceInternalURI "https://sea-cas02.somorita.com/

autodiscover/autodiscover.xml" -AutodiscoverServiceSiteScope 

"Site-SEA","Site-TOL"

Set-ClientAccessServer -Identity "tol-cas01" 

-AutodiscoverServiceInternalURI "https://tol-cas01.somorita.com/

autodiscover/autodiscover.xml" -AutodiscoverServiceSiteScope 

"Site-SEA","Site-TOL","Site-MSY"

Set-ClientAccessServer -Identity "tol-cas02" 

-AutodiscoverServiceInternalURI "https://tol-cas02.somorita.com/

autodiscover/autodiscover.xml" -AutodiscoverServiceSiteScope 

"Site-SEA","Site-TOL","Site-MSY"

Set-ClientAccessServer -Identity "msy-cas01" 

-AutodiscoverServiceInternalURI "https://msy-cas01.somorita.com/

autodiscover/autodiscover.xml" -AutodiscoverServiceSiteScope 

"Site-TOL","Site-MSY"

Set-ClientAccessServer -Identity "msy-cas02" 

-AutodiscoverServiceInternalURI "https://msy-cas02.somorita.com/

autodiscover/autodiscover.xml" -AutodiscoverServiceSiteScope 

"Site-TOL","Site-MSY"

When clients perform Autodiscover, they will only match the records for those Client Access servers that match the site they are currently in.

Clients in Seattle will only match the SEA-CAS01, SEA-CAS02, TOL-CAS01, and TOL-CAS02 SCP objects. Because there are multiple objects, they will perform their initial discovery to TOL-CAS01 (this was the last server configured), which will then return URLs for the servers in the Seattle site.

Likewise, clients in New Orleans will only match the MSY-CAS01, MSY-CAS02, TOL-CAS01, and TOL-CAS02 SCP objects. Because there are multiple objects, they will perform their initial discovery to MSY-CAS01, which will then return URLs for the servers in the New Orleans site.

Clients in Toledo will match all six SCP objects. Because there are multiple objects, they will perform their initial discovery to MSY-CAS01, which will then return URLs for the servers in the Toledo site.

If these are not the required behaviors, you should take a close look at the Exchange 2007 Autodiscover white paper, which can be found on the Microsoft website at http://technet.microsoft.com/en-us/library/bb332063.aspx. Although this paper is for Exchange 2007, the concepts transfer to Exchange 2010 without much damage.